<!DOCTYPE html>
<html lang="zh-cn">
  <head>
    <meta charset="UTF-8">
    <title>Sucha's Blog - Welcome</title>
    <meta name="generator" content="MarkdownProjectCompositor.lua">
    <meta name="author" content="Sucha">
    <meta name="keywords" content="suchang, programming, Linux, Lua">
    <meta name="description" content="Sucha's blog">
    <link rel="shortcut icon" href="../images/ico.png">
    <link rel="stylesheet" type="text/css" href="../styles/blog.css">
    <link rel="stylesheet" type="text/css" href="../styles/prism.min.css">
    <style id="site_theme"></style>
  </head>
  <body>
    <div id="body">
      <div id="text">
	   <!-- Page published by cmark-gfm begins here --><h1>Sucha's Blog ~ Welcome</h1><div class="date">25年8月30日 周六 21:56</div>
<h2>iOS GCD （Grand Central Dispatch）的一些探索</h2>
<p>面试遇到了相关问题，答得很烂，才发现自己之前只是粗浅地使用，并未理解。</p>
<p>代码是类似这样的</p>
<pre><code class="language-objc">- (void)exampleFunction {
    dispatch_queue_t queue = dispatch_queue_create(@&quot;test_queue&quot;, NULL);
    NSLog(@&quot;1&quot;);
    dispatch_queue_async(queue, ^{
        NSLog(@&quot;2&quot;);
    });
    NSLog(@&quot;3&quot;);
    dispatch_queue_sync(queue, ^{
        NSLog(@&quot;4&quot;);
    });
    NSLog(@&quot;5&quot;);
}
</code></pre>
<p>那么其输出顺序将是：</p>
<pre><code class="language-bash">1
3
2
4
5
</code></pre>
<p>更进一步，dispatch_queue_create 如果不指定绑定的 queue，那么其运行就是当前发起 queue 的空间。</p>
<p>看了一下 GCD 的源码，不甚懂，太多条件编译了，以及宏代码。</p>
<p>问了一下 AI，pthread、NSThread、GCD、NSOperationQueue 的区别，大概如下</p>
<ul>
<li>pthread 是 POSIX 标准定义的，操作系统调度的最小单元，线程的 C/C++ 接口</li>
<li>NSThread 是 pthread 的 ObjC 的封装，方便使用</li>
<li>GCD 管理的是可运行的闭包 block，具体实际运行在哪个 thread、CPU 核上，是由 GCD 库调度的</li>
<li>NSOpeationQueue 直观了闭包的运行、suspend、resume、cancel，底层实际上是 GCD 的 dispatch_queue</li>
</ul>
<p>在 iOS 上用的最多的是 GCD，GCD 创建的时候，可以设定是串行、并行，优先级等，但不能指定其底层 thread，或者关联到自己创建的 NSThread 上。</p>
<p>若提交的任务闭包是一个死循环，那么运行该闭包的 dispatch_queue 会卡住，关联的 thread 会吃满能够分配到的 CPU 资源，才被调度出去。</p>
<ul>
<li>闭包是一个个被调用的函数，如果是串行的 queue，提交的闭包不会被同时调度运行</li>
<li>如果同一个串行 queue 的任务闭包，再次 sync 了新的 block，将会造成死锁</li>
<li>提交到 sync 的闭包，相当于运行了一个引用了数据资源的任务块，与直接运行该闭包函数，感觉没啥不同，只是在调度上，由于串行 queue 的闭包是顺序执行的，那么在该 sync 的闭包之前提交的所有 async 闭包，都会被先调度运行，才会轮到该 sync 闭包调度运行</li>
<li>提交到该 queue 的闭包，运行的线程空间，是其优先级指定的线程，比如创建了 background queue，在主线程 sync 了该 queue 的闭包，主线程堆栈会被保存，GCD 将调度到 queue 关联的线程运行完闭包后，才会回到主线程恢复堆栈继续</li>
</ul>
<p>以上串行 queue 的调度逻辑，体现在上面例子代码“2”、“4”的输出顺序上，async、sync 闭包运行的 queue 空间，也是该 queue 创建时候的空间（有另外的 create 接口，提供关联的管理queue，比如不同层级的优先级queue）。</p>
<p>但如果是并行 queue，提交的任务闭包，就有可能被同时调度运行，具体跟该体系的 CPU 核心数量、线程调度资源有关系，但被重入是无法避免的。为了保证数据的一致性，提交到并行 queue 的任务闭包，得自己保证数据一致性。</p>
<p>NSOperationQueue 由于底层仍然是关联的 GCD dispatch_queue，所以逻辑是一样的。</p>
<p>以上，可以看到 GCD 是关注闭包，即逻辑关联的数据，而不需要关注线程空间的创建、销毁、挂起、恢复、CPU 的调度和分配逻辑。</p>
<p>GCD 内建了比如主队列（UI相关）、默认队列、后台队列等等共 5 种 QOS 分配策略的队列。</p>
<p>如果是自己创建的 pthread、NSThread 得通过相关接口，才能设置线程的优先级，但另一方面，如果有些业务逻辑包含其依赖的数据，在一个死循环里面更好处理，那不如就直接用 NSThread，或许比 GCD 的分配更好吧。</p>
<div class="category"><a href="CategoryProgramming.html">CategoryProgramming</a> / <a href="2025-08.html#p2">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年8月30日 周六 21:56</div>
<h2>交管12123——学法减分</h2>
<p>之前老家的车被我开到了深圳，住的离东莞很近，就经常到东莞的超市买东西，反正车一周总要热一次，补电瓶的电的。</p>
<p>经常是下班回来后过去，都 20:30 之后了，那次是看到了红灯，但没管那么多，跟着人家粤S的车后面右转，这回是记 6 分，200 块。</p>
<p>好在 交管12123 app 上，可以学法减分，上面会红点提示，但是如果一次被扣 12 分，就得妥妥的重新考试拿驾照了吧，还有，一年内考试最多可以补 6 分，所以，一年内是有 18 分可以扣的？</p>
<p>所谓的学法减分，首先你得被扣分了，然后才能看减分入口，有网上学习，以及线下公益活动可选。这么热的天，还是学法减分好，首先得申请，通过之后才能看警示视频，之后是考试，20 道题错题少于3道才能过，只能补考一次，时间限制没那么严。</p>
<p>看警示视频每次至少 30 分钟，间隔 5 分钟上报时间，中间有人脸识别流程，时间到了会提示，可以进入下一个环节，进行考试了。</p>
<p>我裸考发现很难考，还是得多学习才能考试通过的。</p>
<div class="category"><a href="CategoryLife.html">CategoryLife</a> / <a href="2025-08.html#p1">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年8月30日 周六 21:36</div>
<h2>凡人修仙传（3）</h2>
<p>电子书凡人修仙传我已经看到慕兰人从对抗到联合了，但只可惜动画进度很慢，才到了慕沛灵自爆贴身侍女这里，韩立从闭关中出来。</p>
<p>谁想到，电视剧都有了，不过我没有会员，都是从夸克下载的，也是断断续续地下载，不是 4k 的不看，要不 27 寸屏幕看着就太粗糙了，蓝瘦。</p>
<p>电视剧的人物南宫婉的嘴是歪的，有仙女之气，但金晨来演，有点太冷了，我先看的是动画，原著里面没有那么多吃醋的场景，动画最多，哈哈哈，电视剧里面人物太冷了，从动画过来的，有点不习惯。</p>
<p>其实看过原著就知道，电视剧很多是借鉴动画的。</p>
<p>比如韩立的师傅李化元，原著里面对于其陨落，是在慕兰人入侵之后，当时韩立已经是落云宗长老了，见到了黄枫谷的弟子们，才知道的；动画里面，李还因为红佛跟云露老祖对抗，戏份还是很多的；电视剧因为篇幅问题吧，这段比较少。</p>
<p>电视剧篇幅的原因，只有 30 集，以韩立从古传送阵离开天南为结束；结束时，也跟动画剧情一样，被王婵追杀，最后王婵看着韩立从古传送阵离开。</p>
<p>电视剧的动画效果，跟动画版比起来，大部分是不如的，不过也有出彩的部分，毕竟真人演，如果有不习惯动画的，真人可以过渡一下。</p>
<p>另外，从凡人的篇幅看，真人版应该也会拍外海的吧，然后看情况也会有其他篇的。</p>
<p>总的来说，还行吧，能看，但看过动画的，就没必要看电视剧了，动画才是最雕的。</p>
<div class="category"><a href="CategoryReading.html">CategoryReading</a> / <a href="2025-08.html#p0">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年7月28日 周日 13:53</div>
<h2>泥潭</h2>
<p>朋友给介绍的小说，这本小说的特点在于故事线，分三个部分，分别从同一事件的三个不同人物（角色）来围绕故事展开。</p>
<p>故事的背景是辛亥革命，主角 1 是其中的保皇派，主角 2 是其中的光复会成员（刚开始留日的时候是带着小辫子，之后逐渐转向了革命），主角 3 是神父，三个不同角色用不同的叙述、表现方式，展开了故事。</p>
<p>故事还可以，最特别的是三个角色，三种不同的叙述方式，以及三条时间线，值得一看吧。</p>
<p>不过，故事叙述比较宏大，像我，得花不少时间才能理清其中的故事线了。</p>
<div class="category"><a href="CategoryReading.html">CategoryReading</a> / <a href="2025-07.html#p2">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年7月19日 周六 20:32</div>
<h2>目录文件索引思考</h2>
<p>比如录像文件循环覆盖的逻辑，按照日分割建立文件夹，之后需要考虑如果存储空间不够，需要删除文件或目录，以及按照时间戳可以快速定位文件。</p>
<p>目前了解到的是都只有纯目录、文件的遍历操作，以及没有空间之后，删除日目录下，某个二级目录，作为存储空间的释放（获取）逻辑。</p>
<p>纯目录、文件的遍历操作，因为是嵌入式，nand 访问 IO 口速率比较低，以及 cpu 较差，所以时间上很慢，接口上为了适应这个限制，限制为 255 个文件后一次返回，之后客户端再次请求，传递进去的参数，是上一次返回的最后一个节点的结束时间。</p>
<p>如果类似 windows thumbs 或者 mac os DS_Store 的缓存文件索引策略，我觉得可以改善这个问题。</p>
<p>创建资源文件前，先创建（更新）索引文件，标记为待完成，资源文件完成后 ，再标记为已完成（open 接口，bit 反转），删除文件目录释放存储空间的时候，也同样更新相关标记就行。</p>
<p>若索引文件损坏或者不可用，逻辑上可以回退到纯目录、文件的遍历操作。</p>
<p>特别是文件查找，如果定义索引文件在日目录一级，日目录里面的文件可以根据二分查找，是相当快的，应该比目录遍历快得多，毕竟只需要读取一个索引文件。</p>
<p>索引文件的更新可能导致损坏，因此我才建议用 open 接口，bit 翻转，用先、后标记来保证，如果没有后标记，更精细的做法是校验相关资源文件，若文件是完整的，则可以更新后标记。</p>
<p>同样的，删除也可以用先、后标记来做，这个都没什么问题。</p>
<p>我觉得这样的操作是安全的，以及通过索引文件来定位、遍历资源文件内容是高效的。</p>
<div class="category"><a href="CategoryProgramming.html">CategoryProgramming</a> / <a href="2025-07.html#p1">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年7月13日 周日 23:11</div>
<h2>嵌入式系统文件更新的一些思考</h2>
<p>目前公司产品（一款嵌入式产品）的固件更新，是使用刷固件（实际上是写固定大小的 jffs2 分区）来做的，大概了解到其更新逻辑是，校验下载后的固件压缩包，校验解压后的固件文件系统包，重启更新（其实还需要教研一次固件文件系统包），刷固件到固定大小的 nand  flash 分区（这个时候还需要校验一次），之后再次重启，挂载相关的 jffs2 分区。</p>
<p>实话说，相对于后端 go 这样 static linked 的程序更新（shipping），固件程序的更新实在是太麻烦了，一方面 nand 存储不可靠（虽然 SD 卡等 nand 存储，主控本身保证了数据安全），另外一方面，文件系统挂载为只读处理也是问题，以及刷机，多次重启，很耗费时间，从最开始的 5 分钟慢慢成了现在的 10 分钟。</p>
<p>所以，我想能否改成这样的逻辑：</p>
<p>比如类似 nginx -r 重启加载某个进程（假设都是 linux 的系统），一个 master 进程，下面多个 app 进程（看业务需求），更新逻辑是：</p>
<ul>
<li>kill 掉业务 app 进程（可能是多个），拉起更新（刷新）进程</li>
<li>卸载 app 业务分区（假设仍是 jffs2）</li>
<li>校验固件压缩包，校验固件解压包，写入 jffs2 分区，校验 app 业务分区</li>
<li>重新挂载 jffs2 分区</li>
<li>kill 掉刷新进程，拉起业务进程 loading 进程</li>
<li>loading 进程每次启动（包括冷启动，热启动），都会校验 app 业务分区，然后再拉起 app 多个业务</li>
</ul>
<p>这样，用多进程的方式来进行热更新，其效率会比目前冷启动的效率高得多，当然这里面有不少细节需要确认</p>
<ul>
<li>app 业务分区，在多个业务进程被 kill 掉后，是能够被卸载的</li>
<li>app 业务分区被卸载后，能够被正常写入（或者挂载为 RW 分区，直接更新二进制包，启动只校验二进制包，其实也就是 .so）</li>
<li>app 业务分区有最新的 .so，worker 加载失败后，master 进程能够拉起非更新分区的旧版的 app 业务进程，并通知到 HOST 支持再次更新</li>
</ul>
<p>这样 HOST 仍能随时更新固件里面的业务进程，这要比单纯仅只读 jffs2 挂载的业务分区，更新的效率高得多。</p>
<p>当然，上述的想法，是基于一些我对固件更新的业务逻辑的了解上，做出的一些改进。</p>
<p>距离我上次在福建做类似的固件开发（linux 嵌入式业务开发），已经超过了 13 年，之前的两个不同产品的更新，一个是完全依赖网络（网卡的 IPXE），一个是 EEPROM，然后再带 nand flash（忘记多大了），跟现在的应该是有差别。</p>
<p>大概思路是这样，如果有可能的话，我觉得改进的效率是很高的，应该要比现在 10 分钟起步的更新快得多得多，但是要求是 linux 的多进程管理，以及同步的能力吧。</p>
<div class="category"><a href="CategoryProgramming.html">CategoryProgramming</a> / <a href="2025-07.html#p0">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年6月15日 周日 21:15</div>
<h2>凡人修仙传（2）</h2>
<p>是从 B 站的动画开始看的，一开始的动画有点粗糙，到后来大概八九十集，还是百来集的时候，4K 动画的精致程度，已经无与伦比，故事情节更是扣人心弦，每周一集的更新进度，让人等不及。</p>
<p>于是开始看小说了，之前买的汉王 10.3 寸屏纸质书开始派上用场，看书的效果、效率、手感都很不错，相当好评，只是我看小说的进度还是偏慢，大概只看了 1/10，远远赶不上动画的进度。</p>
<p>这篇网络小说我是大大推荐的，故事情节很不错。</p>
<p>当然动画更是大大推荐，故事情节相比小说，还优化了，动画效果更进一步，我觉得当前同期的动画，灵笼第二季的动画效果也远比不上现在的凡人修仙传，不过凡人修仙传每集的长度大概 20 分钟，灵笼大概有 40 分钟，以及凡人修仙传也不是每个角色都能得到这样精致的动效，只有稍微中心点的人物才会得到这样的资源投入。</p>
<div class="category"><a href="CategoryReading.html">CategoryReading</a> / <a href="2025-06.html#p0">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年5月24日 周六 19:55</div>
<h2>iOS 下图表的绘制</h2>
<p>工作中碰到，没有用之前支持 K 线的第三方库，而是自己摸索了一下，因为需求也没有高的要求。</p>
<h3>UIBezierPath 曲线的平滑</h3>
<p>用直线绘制其实也是可以的，相交部分用圆角过度还行，但只就美观效果来说，跟曲线的拟合相比差远了。</p>
<p>可惜 iOS 下绘制曲线用的 UIBezierPath 仅支持有限点的控制，后台下发的数据可不止那几个点，这个时候就用到下面说的曲线的平滑了。</p>
<p>网上说到的曲线平滑算法有不少，而我只会使用 UIBezierPath 来绘制，github 上找到的有 2、3 个都是可以用的，比如下面这个：</p>
<ul>
<li>https://github.com/Ramshandilya/Bezier</li>
</ul>
<p>绘制出来的还是挺好看的，唯一的缺点在于，虽然都经过了数据点，但数据点并不是在区域范围的极值点上，也就是说，数据点在曲线里面不是曲线的最高、最低点，曲线的最高、最低值，在数据集的范围之外，这就挺不好的。</p>
<p>不过就曲线平滑这一点看，上面这个库还是很好用的。</p>
<h3>X、Y 值的放大、缩小比例</h3>
<p>二维的图表，为了在一张图表上表示所有的数据点，X、Y 轴上是需要刻度单位的，在 app 上虽然各图表的大小都一样，但是可能喂进去的数据各不相同，很多时候，并不需要同样的刻度来表现曲线，否则有的曲线，在刻度间隔较大的情况下，视觉上更像一条直线，表现不出具体的变化了。</p>
<p>这个时候需要将 Y 轴的刻度变小，以上原因，不管是 X 轴、Y 轴，都需要根据数据集的范围，选择一个合理的刻度变化（在 UI 大小相同、而数据集不同的情况下）。</p>
<h3>数据集到 UI、UI 到数据集的比例映射</h3>
<p>我记得之前看的第三方库，用的是 matrix 来做变换的，我自己操作的过程中，没有懂这个，反正都是线性的，索性单独建立 X、Y 轴的比例映射了。</p>
<p>就是转换的时候麻烦一点，显示的时候是 data -&gt; ui mapping，用户选择图表点的时候，是 ui -&gt; data mapping。</p>
<p>以上，就是手搓 iOS 图表绘制的几个要点了，最困难的点，是使用 UIBezierPath 曲线来平滑，得用到看不懂的代码，可选的方案是绘制直线，转交点用 round 来做，效果吧，勉勉强强，也是能用的。</p>
<div class="category"><a href="CategoryProgramming.html">CategoryProgramming</a> / <a href="2025-05.html#p0">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年4月20日 周日 12:09</div>
<h2>凡人修仙传（1）</h2>
<p>很早就听说了凡人修仙传小说，但当时不喜好网络小说，就没读。现在 B 站有凡人修仙的番剧，心痒痒，就从第一集看了起来。</p>
<p>先说动画质量，明显第一集时候的动画质量相当一般，但是看到后面，大概七八十集的时候，动画质量好不少了，到了目前的一百四十集，乖乖，动画质量都不能用好来形容了，简直不能更好了。</p>
<p>4K 画质下，人物模型的精细程度，AOE 攻击的效果，我感觉都是拉满的，对比最新一档的哪吒3，都不会输，而这个是每周更新的番剧，这个质量也太好了吧。对比一些日漫有名的老动画，在效果上，老动画没法看。</p>
<p>我现在都犹豫着要不要读一遍小说算了，因为动画番剧一周一集的更新太慢了，太难等了。</p>
<div class="category"><a href="CategoryReading.html">CategoryReading</a> / <a href="2025-04.html#p0">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年3月23日 周日 21:04</div>
<h2>AUGraph (1)</h2>
<p>说到 iOS 的音频播放，以及录音部分，之前我从未接触过，之前的音视频处理简单点说，其实就是纯 MP4 流的播放，要么是 AVPlayItem 用 https URL 的 mp4、要么是 HLS，反正都是其他组同事封装好的库。</p>
<p>现在遇到的是纯音频的处理，好不容易网上搜到了 2 篇相关的介绍：</p>
<ul>
<li><a href="https://blog.csdn.net/CSDNedu/article/details/143510532">01｜iOS平台音频渲染（一）：使用AudioQueue渲染音频</a></li>
<li><a href="https://blog.csdn.net/CSDNedu/article/details/143510539">02｜iOS平台音频渲染（二）：使用 AudioUnit 渲染音频</a></li>
</ul>
<p>但是总有些限制，比如因为更倾向于 8KHz 的输出（低质量的人声），导致 AudioQueue 其实要处理起来也复杂，反正按照网上的东拼西凑的教程，没能搞好从 48KHz 转 8KHz 的 PCM 流。</p>
<p>倒是在 github 上找到了使用 AUGraph 的方案，使用 AUGraph 串联起一个 AudioUnit（貌似不需要 AUGraph 也是可以的），每个 AudioUnit 包含 input（录音）、output（播放）两个 path（大概意思）。</p>
<p>每个 path 又涉及到输入、输出，比如对于播放，输入就是提供 PCM 流，输出则是连接到硬件喇叭、耳机、蓝牙等等。对于录音，输入则是硬件录音，输出则是转频率后的 PCM 流。</p>
<p>这样就很方便了。</p>
<p>当然细节上，还有 AVAudioSession 的处理，其实算是一个独占或者公用音频硬件资源的配置管理类，大概意思。</p>
<p>但仅仅这样是不够的，因为如果距离较近，则环境音、人声都可能导致回音，苹果硬件给提供了一个降人声回声的处理，但感觉没啥用；另外就是很容易就遇到啸叫的问题，而苹果是没有提供这方面的处理的。</p>
<p>有些声音处理的第三方库貌似对啸叫有抑制的作用，但我看了一下源码，其实也是 AUGraph 组的，没能看出如何处理啸叫的，让人头痛。</p>
<p>还有就是硬件转码 48KHz 到 8KHz，感觉质量有点差，原因不清楚。</p>
<p>反正效果一般般，大概这样吧。</p>
<div class="category"><a href="CategoryProgramming.html">CategoryProgramming</a> / <a href="2025-03.html#p0">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>

<div class="date">25年2月28日 周日 22:26</div>
<h2>三角洲行动</h2>
<p>春节前迷上了三角洲行动，还买了 2 个月的高级安全箱，但是水平实在有限，大部分的情况下，只能当个小糖人，虽然拿了不少大红，但实际上我是想找一个 CS 的平替，那么多枪可以玩，刚入坑感觉也是蛮好的。</p>
<p>但是现实中的大坝会教你做人，特别是机密大坝，摸金模式下，要自己计算装备价值，装备越好，秒人越快，这也得看系统给你的匹配对手，有时候再好的枪，也有没能扣动扳机就倒下的可能，特别是面对行政楼的牢大时，锁你的头无可奈何，得真刀上去实干。</p>
<p>跟线上朋友去过几次巴克什，一直拖后腿，只好退回大坝，自己去过一两次航天，死的莫名其妙，又退回大坝。</p>
<p>相比 CS，入坑要困难许多，对于年轻人应该没啥问题，特别是玩吃鸡过来的，腰射，举枪瞄准等等，还有左右晃头，对于直接 CS 一步到位的人，要熟悉的可太多了。</p>
<p>摸金模式下，要非常小心，才能用低装备打高风险对手，毕竟时间就是多射的几发子弹，出其不意，才能趁其不备。</p>
<p>话虽然是这么说，即便是有最低装备要求的机密大坝，也试过几乎没有收获的行动，有时候是我们半途加入，对方早就摸空了，还有就是第一个去到，5 秒之后立即短兵相接，给你思考的时间，只有短短的不到 10 秒钟，感觉要是上班，一天玩不了几轮。</p>
<p>所以，即便是最低限度的拿红，其实概率也没有想象中高，再说那么累偷摸进，偷摸出，小糖人拿红可太累了。但是因为自己的竞技水平问题，跟别人对枪，胜算很小，其实也没有什么游戏中的出路，只有当小糖人，被别人打，但是又不是每次进去能拿什么东西，接触时间很短对战就结束，但要从地图边缘进入到密集对战区，又需要很长时间，最后磨掉了耐心。</p>
<p>哎，就是公司加班变多不得不放下了。</p>
<p>大战场玩过不少，但是里面机哥太多了，前面几局对面都是机哥小糖人，逗你开心，到了后面，发现是我方机哥都缩着不动，还有各种穿墙、消失看的太多，举报也很难，对方的名字你都看不到，有没沙你，咋举报呀。</p>
<p>见过太多，类似于一夫当关、万夫莫开的，几十号人持续不断冲击，打不过对方一个人的，有死亡录像都打不过，这个就难评，不如自动划一个死亡禁区好了。还有对方有时候赢得莫名其妙的，人家算的很准，前面都硬推不动我方的，后面人家一堆人过来冲一波占了据点，很快游戏就结束了，这。。。</p>
<p>我还不如去摸金模式呢，我好歹还是个小糖人呢，大战场是真的四得不明不白的。</p>
<p>吐槽完毕，貌似有 3 周没玩了，戒了。</p>
<div class="category"><a href="CategoryLife.html">CategoryLife</a> / <a href="2025-02.html#p0">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>
<!-- Page published by cmark-gfm ends here -->
  <div id="foot">2004-<script>var d = new
	Date();document.write(d.getFullYear())</script> &copy;
	Sucha. Powered by MarkdownProjectCompositor.
  </div>
  </div><!-- text -->
  <div id="sidebar">
  </div><!-- sidebar -->
  <script src="../js/prism.min.js" async="async"></script>
  <script src="../js/blog_sidebar.js"></script>
  </div> <!-- body -->
</body>
</html>